|
|
|
|
|
|
|
object-oriented project depends on an architect's competence. If you develop software as a part-time commercial hobby, you should practice developing object-oriented software several times, using the concepts taught in this book, before selling the software publicly. This will reduce your customer service costs and give you more free time to enjoy life. |
|
|
|
|
|
|
|
|
Proper executive sponsorship of a project increases the chance of finding and hiring the right technical architects and/or business analysts but cannot give a 100% assurance of this. Inexperienced technical leaders might not know how to adjust a given object-oriented methodology to the dynamics of user and executive behavior. This alone produces inadequate use cases (if any) and faulty system architectures. Other detracting factors include the inability to transition a project from one iteration to another, inability to give technical advisories to less experienced stakeholders in the project, and inability to manage the artifacts of the project. In essence, inexperience among the top echelon of a project's technical staff can have a devastating effect on the outcome of a project and its use cases. |
|
|
|
|
|
|
|
|
Impatient Software Developers and Programmers |
|
|
|
|
|
|
|
|
Let's assume you have reasonably proper executive sponsorship, knowledgeable project managers, and proactive user involvement in conveying use cases, so you're able to develop a sound architecture for the system. Because many Visual Basic programmers haven't embraced object-oriented programming, the odds of hiring impatient developers are good. Why is this important? Because many programmers feel that OOP minimizes individualistic efforts, a threat to programmer creativity. Many others feel that reading project artifacts and spending time following design models are useless activities. Of course, such sentiments couldn't be farther from the truth, but they persist. |
|
|
|
|
|
|
|
|
Impatient developers have a tendency to take shortcuts, resorting to the spaghetti-style (disorganized) coding that is prevalent among many developers. User input is minimized to maximize programmer satisfaction. Such developers frown on anything resembling a use case, which means that the system's architecture will likely be faulty, to say the least. |
|
|
|
|
|
|
|
|
Always remember that the fundamental architecture of the proposed system starts in the mind of your intended user. This means that you must be very patient, sometimes very gentle, with your users in order to maximize the effectiveness of the requirements you receive. These requirements become the use cases by which you develop the proposed application. As with any business, you develop an application to solve a user's problem. A writer writes a book in hopes that others will read it. Likewise, you develop an application with the goal that others (or you) will use it. |
|
|
|
|
|
|
|
|
Alas, as with any human interaction, you're not going to please everyone. Object technology represents a huge paradigm shift, not only for programmers but also for users. If |
|
|
|
|
|